The present invention relates generally to tracking and data management systems, and more particularly to inventory tracking and data management systems useful for determining information in a supply chain or similar application.
In recent years, ever more attention has been paid to accurate location determination and efficient allocation of items in supply management systems. Such systems can include warehouse management systems, supply chain management systems, inventory management systems, enterprise resource planning systems, and the like. Merely by way of example, modern warehouse management systems (“WMS”) often are complex software packages that run on top of a relational database management system (“RDBMS”), such as the Oracle 10g™ RDBMS available from Oracle International Corporation of Redwood Shores, Calif.
A key technology being used with WMS is Radio Frequency Identification (“RFID”). As known in the art, an RFID “tag” can be applied to an item, such as an item of inventory, so that the presence of an item can be sensed when that item passes near an RFID detector or other such sensor. For example, a retailer may utilize RFID tags on items in order to quickly determine how much inventory of a certain item the retailer has in stock. An RFID tag typically includes an RFID chip and a transmitter, which can take the form of an antenna positioned about the RFID chip. The antenna/transmitter comes in many forms as known in the art, such as spirals or other complex patterns. RFID tags have advantages over previous tracking technologies, such size and type could have an identical bar code attached thereto. A retailer could then individually scan all bottles of soap in the store, and determine the number of bottles of a certain type and size in the store. Such an approach is not ideal for many applications, as it requires individually scanning each item. Further, it only contains information identifying a type and size of a particular product, and does not contain any information about that particular instance of the product.
RFID tags, on the other hand, allow for automated bulk scanning and tracking, and can provide unique information about each particular instance of an item or tag. An RFID tag can be read by any appropriate detector within a given radius, such that a pallet of products passing near an RFID reader or other sensor, such as may be attached to a shipping or receiving door, for example, can allow each of the items on the pallet to be scanned virtually simultaneously as the pallet passes by the antenna of the RFID reader. The range of the RFID tag and the reader can depend in part on the type of tag, such as whether the tag is an active tag (including an internal battery) or a passive tag (powered by radio waves from the RFID reader).
Further, the information read by the RFID reader for each item can identify each particular instance of an item, as well as other appropriate information. Current standardization efforts for RFID tags, such as are being set forth the EPCglobal consortium, provide for 96 bits of identification information in each individual tag in a set format. The use of 96 bits in a standard format allows each tag to include, for example, bits representing the company or entity (such as an identifier assigned by UCC.EAN), bits representing the product, item, or object class, and bits representing a unique serial number for that particular instance of the product. There is a also provision for 128 additional user bits of data which can store additional identification information which can be read by a Gen2 Compatible RFID reader. Because different formats may be appropriate for different industries, the tag also can include a few header bits indicating the format to be used in interpreting the tag information.
As RFID technology becomes more widely accepted, entities such as large retailers are increasingly mandating that their suppliers include RFID tags with each shipment received by that entity, and are moving toward mandating that each individual item include an RFID tag. In another example, FDA regulations mandate that each instance of pharmaceutical packaging be separately identifiable in order to determine information such as lot number and expiration date for each instance. Further, various entities a particular instance.
Considering an exemplary flow of goods 100 shown in FIG. 1(a), Manufacturer A 102 may sell a first type of goods 104 through Primary Wholesaler A 106. Manufacturer B 108 may sell a second type of goods 110 through Primary Wholesaler A 106. Primary Wholesaler A may sell the goods of Manufacturers A and B through Secondary Wholesaler B 112, who in turn may sell to a retailer such as Pharmacy A 114. When an item is shipped and/or received from any of these entities, the RFID tag of the item can be detected and the information fed to a database that can be accessed by the other entities in order to determine the location of that item. For example, as shown in the arrangement 120 of FIG. 1(b), each entity may have a respective database 122, 124, 126, 128, 130 that is accessible by each other associated entity, so that each entity along the supply chain can run queries against the databases, and capture information to the databases, in order to determine the location of an item in the supply chain.
In another example, FIG. 2 shows a supply chain 200 wherein each of a Manufacturer 202, third party carrier 204, Customs Agency/Location 206, Carrier 208, and Importer 210 might scan RFID tags and store the data for access in a local database (or remote or shared database) by any of the other entities.
Each time an RFID tag is read by a tag reader or other appropriate hardware used in the art for scanning, sensing, or detecting tags, an RFID event is triggered. An RFID event typically involves the reading of an RFID tag and storing of the relevant information (such as is contained in the 96 bits), as well as the time of the event and the location of the reader (or other device) sensing the tag. This information then can be passed to an interface that determines whether the event is a relevant business event and, if so, the information can be associated to an appropriate business object and/or stored in an appropriate location for later retrieval.
FIG. 3 shows an example 300 of event types that can be generated in accordance with the proposed EPCglobal standard. These events can include Object Events 302, Aggregation Events 304, Quantity Events 306, and Transaction Events 308, each of which can be stored in a relational database 310 for querying of data through an appropriate query interface 312 and/or capturing of data through an appropriate capture interface 314. The events can be triggered and directed through an appropriate event tracking system as known in the art. The RFID events captured typically are considered to answer four questions, including “what” (e.g., the EPC number, manufacturing data, and transactional data), “where” (e.g., the location—fixed or moving), “when” (e.g., event time or record time), and “why” (e.g., the business process step, the product state, and the currently conditions). These can be matched with the four standard XML events described with respect to FIG. 3, which can be accepted by the relevant capture interface and returned by the query interface. These events also can be originated by enterprise systems as well as RFID reads. The attributes of each event can be extended for each event.
An example of such an event tracking system 400 is shown in FIG. 4. In this system, an RFID Tag 402 of an appropriate Tag Protocol passes within sufficient proximity of an RFID Reader 404, so as to generate an RFID event. The RFID Reader can be managed via a Reader Management Interface and/or Module 406. The RFID event is passed through a Filtering and Collection Module 408 (referred to as RFID middleware), and Interface 410 before being captured by a Data Capturing Application 412. The Data Capturing Application can capture EPCIS data (Electronic Product Code Information Service), for example. The event information then is written to a Data Repository 414, such as the EPC databases shown in FIGS. 1(b) and 2. The Data Repository can be part of a service module 416, which can include the query and capture interfaces mentioned above. Various Subscribers 418, 420 to the service then can query data from the Data Repository to which those subscribers have access. Various applications and services 422, 424, 426, 428 can be built on top of the service layer.
In the system of FIG. 4, the capture and query interfaces are standardized to enable functionality such as track and trace, product authentication, and diversion detection across supply chain partners across multiple industries. For security purposes, each trading partner can maintain their own data, with events being distributed with trading partners on an on-demand bases. The events can be routed to existing enterprise applications, with no vendor “lock-in” in terms of data formats, transport protocols, etc.
Various problems can arise in such a system, however. For example, there is no current standardized way to ensure that any particular data for an entity can only be seen by certain entities along the supply chain. Further, as each entity maintains its own data, there can be problems with loss of data and data reliability. There also can be issues with handling incomplete data and/or handling data for different industries.